home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
inet
/
ddn_news
/
bltn_50.txt
< prev
next >
Wrap
Text File
|
1991-07-10
|
8KB
|
194 lines
**********************************************************************
DDN MGT Bulletin 50 DCA DDN Defense Communications System
23 Dec 88 Published by: DDN Network Info Center
(NIC@SRI-NIC.ARPA) (800) 235-3155
DEFENSE DATA NETWORK
MANAGEMENT BULLETIN
The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities. Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the SRI-NIC host [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest". The pathname
for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************
SUBJECT: Worm (Benign)
APPLICABLE OPERATING SYSTEM: DEC VMS
PROPAGATION: Propagates via DECNET protocols, not TCP/IP protocols
STATUS: Fix is enclosed
VALIDATION: The fix has been forwarded to the CERT for validation, but
validation has not been completed. But in order to provide timely
information to our subcribers, this fix is being made available "as
is". It was provided by a host administrator on the NASA SPAN/DOE
HEPNET network. We recommend that you contact your vendor and refer
to the vendor documentation listed below before attempting to implement the
fix.
PROBLEM: On Friday, 23 December, Gerard K. Newman of the San Diego
Supercomputer Center reported a Christmas Eve computer worm (not a
virus) called "HI.COM". This worm appears to be a benign Christmas
greeting from "Father Christmas".
ESSENTIAL CONSIDERATIONS: The recent Internet Virus has sensitized the
telecommunications community to the potential threat of worms and
viruses. However, "HI.COM" appears to be a prank and nothing more:
(A) It only affects VMS machines connected to DECNET.
(B) It does not use TCP/IP, thus it cannot "infect" the Internet
(or MILNET/ARPANET).
(C) It does no harm (all it does is send a "stop computing and go
home" message after midnight on Christmas Eve).
(D) It has safeguards against running multiple copies of itself on
the same machine.
(E) It will terminate itself after completing its mission (at 00:30
on the 24th).
SYMPTOMS OF INFECTION: Some steps to take to determine if your system has
been infected are:
(A) Check your accounting files and NETSERVER.LOGs in your default
DECnet accounts for a file called HI.COM.
(B) Check your processes for one named MAIL_178DC.
A FIX:
There is a worm loose on NASA's SPAN/DoE's HEPNET network, which is an
international DECnet-based network. The worm targets VMS machines, and
can only be propagated via DECnet.
The worm itself appears to be benign, in that it does not destroy files
or compromise the system. It's purpose appears to be to deliver a
Christmas message to users starting at midnight on 24 Dec 1988. It
does have a hook in it to monitor it's progress; it mails a message
back to a specific node (20.117, user PHSOLIDE) containing an identifying
string of the "infected" machine.
The worm exploits two features of DECnet/VMS in order to propagate itself.
The first is the default DECnet account, which is a facility for users who
don't have a specific login ID for a machine to have some degree of
anonymous access. It uses the default DECnet account to copy itself to a
machine, and then uses the "TASK 0" feature of DECnet to invoke the remote
copy.
There are several steps which you can take to protect yourself from this
kind of attack. The easiest (and most restrictive) is to disable the
default DECnet account on your machine altogether. This can be done with
the following commands from the SYSTEM or other suitably privileged account:
$ Run SYS$SYSTEM:NCP
Purge Executor Nonprivileged User Account Password
Clear Executor Nonprivileged User Account Password
^Z
This requires that everyone who accesses your resources via DECnet to have
a legitimate login ID or proxy login account on your machine (proxy logins
are discussed in detail in chapter 7 of the "Guide to VMS System Security",
see below).
You can take less restrictive steps to protect your machine while still
maintaining some degree of default access. If you wish to keep the ability
for users to copy files to the default DECnet account but wish to prevent
them from copying DCL command procedures there and then executing them you
can issue the following commands (again from the SYSTEM or other suitably
privileged account):
$ Run SYS$SYSTEM:NCP
Clear Object Task All
^Z
You must then edit the file SYS$MANAGER:STARTNET.COM, and add the line
CLEAR OBJECT TASK ALL
AFTER the line which says
SET KNOWN OBJECTS ALL
This has the side-effect of disabling users from executing any command
procedure via DECnet that the system manager has not defined in the
DECnet permanent database. These steps alone are not sufficient to
prevent copies of the virus from being copied to your machine; but they
will prevent it from being executed. To prevent copies of this specific
virus from being copied to your machine you can issue the following
commands (from the SYSTEM or other privileged account):
$ Set Default your-default-decnet-directory
$ Create HI.COM
$ Stop/ID=0
^Z
$ Set File/Owner=[1,4]-
/Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM
This prevents anyone from copying a file called "HI.COM" into your default
DECnet account; however, other files can be copied there unless you disable
access to the DECnet object FAL (the File Access Listener) from your default
DECnet account. This can be done by creating a specific account for FAL
(using the AUTHORIZE utility) with a seperate UIC, default directory, and
minimal privileges and forcing the FAL object to use that account. The
following sequence of commands are an example (these commands also require
that they be issued from the SYSTEM or other suitably privileged account):
$ Set Default SYS$SYTEM
$ Run AUTHORIZE
Add FAL/UIC=[some-unused-UIC]/Owner="DECnet default FAL"-
/Password=randomstring/Device=disk-device/Directory=[some-directory]-
/Flags=(DISCTLY,DEFCLI,CAPTIVE,LOCKPWD)/NoBatch/NoLocal/NoDialup-
/NoRemote/Privileges=(TMPMBX,NETMBX)/DefPrivileges=(TMPMBX,NETMBX)-
/LGICMD=SYS$SYSTEM:FALLOG.COM
^Z
$ Run NCP
Define Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
Password same-random-string
Set Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
Password same-random-string
^Z
$ Create FALLOG.COM
$ V := 'F$Verify(0)
$ Write SYS$OUTPUT ""
$ Write SYS$OUTPUT "''F$Time()' -- Node ''F$Logical("SYS$NODE")'"
$ Write SYS$OUTPUT "''F$Time()' -- Remote file access from:"
$ Write SYS$OUTPUT "''F$Time()' -- User: ''F$logical("SYS$REM_ID")'"
$ Write SYS$OUTPUT "''F$Time()' -- Node: ''F$Logical("SYS$REM_NODE")'"
$ Write SYS$OUTPUT ""
^Z
This sequence of commands separates the FAL account from the default DECnet
account, and you can use file protections to enforce that the FAL account
cannot access files in the default DECnet account and vice-versa. The
command file FALLOG.COM above will log all remote file accesses in the
file NETSERVER.LOG in the directory specified for the FAL account above.
The FAL program can supply additional logging information; contact your
DIGITAL software support person for further details.
Further steps can be taken to restrict access to your system. These
steps are discussed in detail in the "Guide to VMS System Security", DEC
order number AA-LA40A-TE, dated April 1988. See in particular chapter 7,
entitled "Security for a DECnet Node".
For general information about this patch call the CERT or the Network
Information Center at (800) 235-3155.
This represents the best information available at this time to fix this
problem.